Data transfers between host devices and peripheral devices such as magnetic tape drives or disc drives are often executed by a controller. The controller may act with the host to "queue" commands which are intended for the peripheral device. Command queueing results in queued data transfers and, since most peripheral devices operate much more slowly than their hosts, the efficiency of the host is significantly improved.
In a queued data transfer, the controller issues a first command from the queue to the peripheral device. Subsequently, the controller issues a second command and, when execution commences, receives a status report corresponding to the first command. Thus, the controller issues the second command before it is certain that the first command was properly executed. In one sense, the controller is always one command "ahead" of the peripheral device. This technique inherently requires two separate buffers or memories for the storage of status reports. The necessity for two buffers becomes apparent when it is realized that a given status report cannot be transmitted to the controller until execution of the next subsequent command begins. For this reason, one status buffer must store the report for the immediately preceding command while the other status buffer remains ready to receive the report for the command being executed.
The controller and peripheral device must be synchronized in order to maintain the proper status report sequence. The peripheral device may detect synchronization "events" which are dispersed throughout the storage medium or may rely on another type of event. By identifying the synchronization events and comparing them to preselected "target" events, the peripheral device determines when a data transfer may begin and when a status report is available. The peripheral device may transmit this information to the controller through a handshake line or other control device.
Since the controller normally sends a second command without having received a status report for the first, problems arise when there is a loss of synchronization between the controller and peripheral device. For example, if the peripheral device fails to detect a particular synchronization event but does detect the events immediately preceding and following it, the status reports will become incorrectly sequenced as they are transmitted to the controller. A second problem is accounting for the data transfer which immediately preceded the loss of synchronization. If the controller cannot recover the status report for this transfer, it will have to be redone regardless of whether it was valid.
A previous solution to the problem of synchronization loss was to provide the controller with a "timeout" mechanism. This mechanism simply measured the duration of the data transfer and, if a preselected period expired before the occurrence of an expected synchronization event, then a loss of synchronization was assumed. The disadvantage of this technique is that the controller cannot obtain the status report for the transfer which immediately preceded the loss of synchronization, even though that transfer may have been valid. There is also the inherent disadvantage of having to incorporate the timeout mechanism into the controller.